Currently, standards committee IEEE 802.21 conducts intensive research into the international standards associated with media independent handover (MIH) between heterogeneous networks. MIH provides not only a seamless handover but also a service continuity between the heterogeneous networks, resulting in greater convenience for a user who carries a mobile terminal. IEEE 802.21 defines a variety of functions (e.g., an MIH function, an event service, a command service, and an information service (IS) function) as basic requirements.
A mobile terminal (MSS) is indicative of a multi-mode node for supporting at least two interface types. For example, the multi-mode node can support a variety of interface types, such as a wired interface type (also called a wire-line interface type) such as the Ethernet based on an IEEE 802.3 standard specification, a wireless interface type based on IEEE 802.XX standard specifications (e.g., IEEE 802.11, IEEE 802.15, IEEE 802.16), and other interface types defined by a cellular standardization organization (e.g., 3GPP or 3GPP2).
A general Media Independent Handover Function (MIHF) reference model is depicted in FIG. 1. In the figure, MIHF architecture for interaction with other layers and with the remote MIHG is illustrated. In order for the MIHF to provide asynchronous and synchronous services to lower layers and higher layers, Service Access Points (SAPs) such as MIH_MGMT_SAP, MIH_SME_SAP and MIH_SAP along with primitives are defined. MIH_MGMT_SAP defines the interface between the MIHF and the management plane (Management Entity) of different network interfaces and is used for transporting MIH protocol messages between the MIHF and local link layer entities as well as peer MIHF entities. MIH_SAP defines the interface between the MIHF and higher layer entities such as device manager, handover policy control function, transport, layer 3 (L3) mobility management protocol, etc., and is used for MIH configuration and operation. MIH_SME_SAP defines the interface between the MIHF and the Station Management Entity or the Network Management System, and is used for MIG configuration and operation.
FIG. 2 is a structural diagram illustrating a protocol layer of a multi-mode mobile terminal. Referring to FIG. 2, the protocol stack of the multi-mode mobile terminal includes a MAC structure including the IEEE802.11, the IEEE 802.16, and the 3G interface, and locates an MIH function under an Internet protocol (IP) layer. A variety of mobility management protocols are included in a network layer contained in the mobile terminal. The mobile terminal selects a mobility management protocol contained in the network layer according to a mobility management protocol type supported at a point of attachment (POA) to which the mobile terminal is connected, and establishes an IP connection.
The MIH function, an event service, a command service, and an Information Service (IS) will hereinafter be described.
Referring to FIG. 2, the multi-mode mobile terminal includes a physical (PHY) layer, or a first layer (L1), and a Medium Access Control (MAC) layer, or a second layer (L2), for individual modes, and locates the MIH layer under the IP layer. The MIH function located under the IP layer, i.e., the Media Independent Handover (MIH) must be defined between IEEE 802-series interfaces, or between an IEEE 802-series interface and a non-802-series interface (e.g., 3GPP or 3GPP2). The MIH function facilitates a handover process using input values (e.g., a trigger event and information associated with other networks) received from a second layer (Layer 2).
The MIH function may include a plurality of input values based on both user policy and configuration which may affect the handover process. General interfaces among the mobile IP, a third layer (L3) entity such as an SIP (Session Initiation Protocol), and the MIH layer are defined. In this case, the aforementioned interfaces provide the first layer (i.e., the physical layer), the second layer (i.e., the MAC layer), and mobility management information. The MIH function acquires information associated with a lower layer and a network using event and information service (IS) functions.
An upper layer includes an upper management entity for monitoring states and operations of various links contained in a mobile terminal, such that it performs a handover control function and a device manager function. In this case, the handover control function and the device manager may be located at different locations independent of each other, or the handover control function and the device manager may be included as the upper management entities in the upper layer.
FIG. 3 shows an MIH structure and a transmission protocol. In more detail, FIG. 3 shows a mobile terminal function entity including the MIH function, a network function entity, and a transmission protocol. Dotted lines of FIG. 3 are indicative of primitive information and an event trigger, etc.
In order to quickly perform a handover function, a network layer uses information generated from a link layer so that the network layer can quickly re-establish a connection state. The link layer event is adapted to predict the movement of a user, and helps a mobile terminal and a network prepare the handover function.
A trigger for the handover may be initiated from the physical (PHY) layer and the MAC layer. A source of the trigger may be determined to be a local stack or a remote stack. FIG. 4 is a block diagram illustrating a trigger model.
An event trigger provides state information of a current signal, state change information of another network, and future predicted change information. The event trigger further includes change information of the physical and MAC layers or attribute change information of a specific network.
The event types can be classified into a physical (PHY) layer event, a MAC layer event, a management event, a third layer (L3) event, and an application event, for example. There are a plurality of basic trigger events, such as a “Link_Up” event, a “Link_Down” event, a “Link_Going_Down” event, a “Link_Going_Up” event, a “Link_Event_Rollback” event, a “Link_Available” event, a “Link_Parameters_Change” event, an “IP_Renewal_Indication” event, and an “IP_Renewal_Request” event, for example. The above-mentioned trigger events will hereinafter be described with reference to the following tables.
The following Table 1 shows parameters of the “Link_Up” event.
The “Link_Up” event occurs when a second layer (L2) connection is established on a specific link interface and an upper layer is able to transmit third layer (L3) packets. In this case, it is determined that all L2 layers contained in a link have been completely configured. A source of the “Link_Up” event corresponds to a “Local MAC” and a “Remote MAC”.
TABLE 1NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at which eventoccursEventDestinationEVENT_LAYER_TYPEDestination to whichevent is to betransmittedMacMobileTerminalMAC AddressMAC address of MobileTerminalMacOldAccessRouterMAC AddressMAC address of oldaccess routerMacNewAccessRouterMAC AddressMAC address of newaccess routerNetworkIdentifierMedia SpecificNetwork ID used fordetecting subnet changeIP_Renewal_IndicatorPresence or absenceof IP temporaryaddress change necessity0: No change required1: Change required
The following Table 2 shows parameters of the “Link_Down” event.
The “Link_Down” event occurs when the L2 connection is released on a specific interface and L3 packets cannot be transmitted to a destination. The source of the “Link_Down” event is indicative of a local MAC.
TABLE 2NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at whichevent occursEventDestinationEVENT_LAYER_TYPEDestination to whichevent is to betransmittedMacMobileTerminalMAC AddressMAC address ofMobile TerminalMacOldAccessRouterMAC AddressMAC address of oldaccess routerReasonCodeReason for releasedlink
The following Table 3 shows parameters of the “Link_Going_Down” event.
The “Link_Going_Down” event occurs when it is expected that the L2 connection will enter a “Link_Down” state within a predetermined time, and may serve as a signal for initializing a handover procedure. A source of the “Link_Going_Down” corresponds to a “Local MAC” and a “Remote MAC”.
TABLE 3NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at whichevent occursEventDestinationEVENT_LAYER_TYPEDestination to which event is to be transmittedMacMobileTerminalMAC AddressMAC address of MobileTerminalMacOldAccessRouterMAC AddressMAC address of oldaccess routerMacNewAccessRouterMAC AddressMAC address of newaccess routerTimeIntervalTime in msecsPredicted Link_Downtime of linkConfidenceLevel%Link_Down levelpredicted at specifictimeUniqueEventIdentifierUse in event rollbackoccurrence
The following Table 4 shows parameters of the “Link_Going_Up” event.
The “Link_Going_Up” event occurs when it is expected that the L2 connection will enter a “Link_Up” state within a predetermined time, and is used when a long period of time is consumed to initialize a network. A source of the “Link_Going_Up” event corresponds to a “Local MAC” and a “Remote MAC”.
TABLE 4NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at whichevent occursEventDestinationEVENT_LAYER_TYPEDestination towhich event is tobe transmittedMacMobileTerminalMAC AddressMAC address ofMobile TerminalMacNewAccessRouterMAC AddressMAC address ofnew access routerTimeIntervalTime in msecsPredicted Link_UPtime of linkConfidenceLevel%Link_UP levelpredicted atspecific timeUniqueEventIdentifierUse in eventrollbackoccurrence
The following Table 5 shows parameters of the “Link_Event_Rollback” event.
The “Link_Event_Rollback” event is formed by combining the “Link_Going_Down” event with the “Link_Going_Up” event. The “Link_Event_Rollback” event is indicative of a trigger generated when it is expected that the “Link_Up” event or “Link_Down” event will not be generated any more within a specific time on the condition that the “Link_Going_Up” event or “Link_Going_Down” event are transmitted to a destination. A source of the “Link_Event_Rollback” event corresponds to a “Local MAC” and a “Remote MAC”.
TABLE 5NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at whichevent occursEventDestinationEVENT_LAYER_TYPEDestination towhich event is tobe transmittedMacMobileTerminalMAC AddressMAC address ofMobile TerminalMacNewAccessRouterMAC AddressMAC address ofnew access routerUniqueEventIdentifierUse in eventrollbackoccurrence
The following Table 6 shows parameters of the “Link_Available” event.
The Link_Available” event is indicative of an available state of a new specific link, and indicates the possibility of allowing a new base station (BS) or a new Point of Attachment (POA) to provide a link superior in quality as compared to a current BS or a current POA to which a current mobile terminal is connected. A source of the “Link_Available” event corresponds to a “Local MAC” and a “Remote MAC”.
TABLE 6NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at which event occursEventDestinationEVENT_LAYER_TYPEDestination to whichevent is to be transmittedMacMobileTerminalMAC AddressMAC address of Mobile TerminalMacNewAccessRouterMAC AddressMAC address of newaccess routerMacOldAccessRouterMAC AddressMAC address of oldaccess routerIP_Renewal_IndicatorPresence or absence of IP temporaryaddress change necessity0: No change required1: Change required
The following Table 7 shows parameters of the “Link_Parameter_Change” event.
The “Link_Parameter_Change” event is indicative of an event generated when a change of a link parameter value is higher than a specific threshold level. The “Link_Parameter_Change” event includes link layer parameters, for example, a link speed (i.e., a link rate), a QoS (Quality of Service), and an encrypted value, etc. A source of the “Link_Parameter_Change” event corresponds to a “Local MAC” and a “Remote MAC”.
TABLE 7NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at whichevent occursEventDestinationEVENT_LAYER_TYPEDestination to which event is to be transmittedMacMobileTerminalMAC AddressMAC address of Mobile TerminalMacAccessRouterMAC AddressMAC address of new access routeroldValueOfLinkParameterOld value of linkparametersnewValueOfLinkParameterNew value of linkparameters
The following Table 8 shows parameters of the “IP_Renewal_Indication” event.
A new POA (e.g., a base station or POA) of the mobile terminal receives the “Link_Up” trigger signal, and triggers the “IP_Renewal_Indication” event to inform the mobile terminal of a changed or unchanged state of an IP address used for transmitting IP packets to the mobile terminal. The IP address is set to a newly-assigned IP address in the case of a dynamic host configuration protocol (DHCP) system, to a new temporary address (CoA) in the case of a mobile IPv4 system, and to an Autoconfiguration address in the case of a mobile IPv6 system. A source of the “IP_Renewal_Indication” event corresponds to a “Remote MAC” and an “MIH”.
TABLE 8NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at whichevent occursEventDestinationEVENT_LAYER_TYPEDestination to whichevent is to be transmittedIP_Renewal_IndicatorPresence or absenceof IP temporaryaddress change necessity0: No change required1: Change requiredMacMobileTerminalMAC AddressMAC address of Mobile TerminalNetwork IDIP AddressNetwork address towhich mobile terminalis connected inprevious link
The following Table 9 shows parameters of the “IP_Renewal_Request” event.
Upon receiving the “IP_Renewal_Indication” trigger signal indicative of an address re-establishment state, the MIH function of the mobile terminal transmits an “IP_Renewal_Request” signal to a network layer, such that it requests the network layer to re-establish an IP temporary address. A source of the “IP_Renewal_Request” event corresponds to a “Remote MAC” and an “MIH”.
TABLE 9NameTypeDescriptionEventSourceEVENT_LAYER_TYPESource at which eventoccursEventDestinationEVENT_LAYER_TYPEDestination to whichevent is to betransmittedNetwork IDIP AddressNetwork address towhich mobile terminal isconnected inprevious link
FIG. 5 shows event triggers generated when a handover occurs. In more detail, FIG. 5 exemplarily shows triggers generated when a quality of a current access link is deteriorated. The triggers are generated until a new link is established.
A command service allows an upper layer to command a lower layer to perform a predetermined operation. For example, the upper layer transmits a specific command to the MIH function such that the MIH function performs a corresponding operation. The MIH function may also transmit a specific command to the lower layer such that the lower layer performs a corresponding operation. The above-mentioned commands are adapted to transmit a decision of the upper layer to the lower layer, and control the behavior or tasks of lower layer entities.
An information service provides detailed information associated with a network required for both network discovery and network selection, and is designed to be freely accessed by a user over any network. The information service includes a variety of information components, for example, a link access parameter, a security mechanism, a neighborhood map, a location, information indicative of a service provider and other access information, and a link cost (i.e., cost of link).
FIG. 6 is a flow chart illustrating a method for controlling a multi-mode mobile terminal to acquire network-associated information via an information server. As shown in FIG. 6, the multi-mode mobile terminal acquires various network-associated information via the information server, and performs a handover evaluation operation, a link selection operation and a handover procedure.
In more detail, the multi-mode mobile terminal receives an “Information Request/Response” message and a “Response List of Available Networks” message. The multi-mode terminal then acquires various network-associated information from an information server via a current point of attachment (POA) using the “Information Request/Response” message and the “Response List of Available Networks” message, such that the multi-mode terminal performs a handover evaluation operation and a link selection operation. If a new link is selected, the mobile terminal acquires information associated with a new network via the new point of attachment (POA) and an “MIH Resource Query/Response” message.
A variety of protocols (e.g., Mobile IPv4, DHCPv4, Mobile IPv6, and DHCPv6, etc.) for supporting the mobility of a mobile terminal will hereinafter be described.
FIG. 7 is a diagram illustrating operations of a mobile IPv4 system. The mobile IPv4 system requires a variety of functions (i.e., a mobile host function, a home agent function and a foreign agent function), such that it can provide the upper layer with clear mobility. However, if a path is not optimized, there is no need for a correspondent node communicating with the mobile terminal to be changed to another. In this case, the mobile host is indicative of an IP host at which the mobility is supported. The home agent maintains location information associated with the mobile host, and serves as a router for performing tunneling of the mobile host. The foreign agent is indicative of a router for supporting the mobility over a foreign network.
Operations of the mobile IPv4 system shown in FIG. 7 will hereinafter be described. Referring to FIG. 7, the mobile host moves from its home network to a foreign network at step S10. The mobile host then receives an advertisement message currently broadcast over the foreign network, such that mobile host recognizes that it has moved. Thereafter, the mobile host registers a temporary address or care of address (CoA) indicative of a current location of the mobile host with the home agent (HA) at step S20. In this case, the temporary address (CoA) may be equal to an IP address (i.e., foreign agent (FA)-CoA) of the foreign agent, or equal to a co-located CoA temporarily assigned to the mobile host via the DHCP in the foreign network.
Packets transmitted from an external part to the mobile host are transmitted to the home network. These packets are intercepted by the home agent at step S30, which recognizes the movement of the mobile terminal. The home agent having intercepted the above packets sets a destination address of the packets transmitted to the mobile host to an address of the foreign agent (FA) on the condition that the FA-CoA is used. The mobile host then encapsulates the destination address indicative of the FA address and transmits the encapsulated address at step S40. Thereafter, the encapsulated transmission packets are transmitted to the foreign agent (FA), wherein the foreign agent (FA) de-capsulates the received packets to recover original packets and transmits the original packets to the mobile host at step S50.
Packets transmitted from the mobile host to the correspondent node may be directly transmitted via the foreign agent (FA). If an ingress filtering problem occurs, the above-mentioned packets may also be transmitted via a reverse tunnel.
The principal functions required for the mobile IP are an agent discovery function, a registration function, and a routing function, etc., and their detailed description will hereinafter be described.
Agent discovery is indicative of a method for allowing a mobile terminal to determine whether the mobile terminal is connected to its own home network or a foreign network, such that the mobile terminal itself can recognize whether it has moved to another network.
The mobile IP extends a conventional ICMP (Internet Control Message Protocol) Router Discovery (i.e., IETF RFC 1256) to discover a desired agent. The agent advertisement message periodically broadcast by the agents (i.e., home agent and foreign agent) includes a “Mobility Agent Advertisement Extension” message in an “ICMP Router Advertisement” message, and transmits the “ICMP Router Advertisement” message including the “Mobility Agent Advertisement Extension” message. An “Agent Solicitation” message transmitted when the mobile terminal searches for an agent employs the same method as in a conventional “ICMP Router Solicitation” message.
When the mobile terminal moves to another network, a registration function transmits current location information to the home agent, and allows the mobile terminal to receive services from the home network without any change, in such a way that a highly adaptable mechanism is provided.
The mobile IP provides two registration procedures (i.e., FA-CoA and co-located CoA), such that it can establish a temporary address or care of address (CoA) when the mobile terminal moves to another subnet. If the mobile terminal uses the FA-CoA, it performs registration via the foreign agent (FA). If the mobile terminal uses the co-located CoA, the mobile terminal directly performs registration to the home agent. Also, if the FA-CoA is used, the CoA is supplied from a foreign agent via an agent advertisement message, and an IP address of the foreign agent (FA) is used as a temporary address (CoA). If the co-located CoA is used, the mobile terminal receives a temporary address (CoA) via a DHCP server located at the foreign network.
A routing function defines a variety of functions required for properly routing a datagram transmitted to/received from the mobile terminal when the mobile terminal is connected to or accesses a foreign network. The datagram includes a unicast packet, a multicast packet, and a broadcast packet.
A Dynamic Host Configuration Protocol (DHCP) is indicative of a protocol which allows network managers to centrally manage/allocate necessary IP addresses in a network contained in their organization. When computer users gain access to the Internet in an organization, an IP address must be assigned to individual computers. When the network manager centrally manages/allocates the IP address, and a computer is connected to the Internet at points outside the network, the DHCP automatically transmits a new IP address to the computer.
The DHCP employs a rental (or lease) scheme for controlling a given IP address. According to the scheme, the given IP address is valid at a corresponding computer only during a predetermined period of time. A lease time may be changed according to an Internet access time required by a user at a specific location. The DHCP reduces the IP address lease time when many more computers than available IP addresses are used, such that the DHCP can dynamically reconstruct a network.
In order to correctly operate the DHCP, at least one DHCP server and a single DHCP client is included in a corresponding network. Also, the network must further include not only the scope of a TCP/IP address (e.g., 203.224.29.10˜203.224.29.100) but also a gateway address and a subnet mask.
The DHCP client acquires TCP/IP address information from the DHCP server while in operation. However, it should be noted that the acquired TCP/IP address is not permanent. The DHCP server provides a client with a lease address which may periodically expire or be periodically updated.
The DHCP client acquires/maintains the lease address via a plurality of handshake steps, each of which is referred to as a state. There are a plurality of client DHCP states, i.e., an initialization state (INT), a selecting state (SELECTING), a requesting state (REQUESTING), a binding state (BOUND), a renewing state (RENEWING), and a re-binding state (REBINDING), etc.
FIG. 8 shows a DHCP message format. FIG. 9 is a flow chart illustrating operations of a DHCP client-server model, and shows a method for allowing the DHCP client to automatically receive an IP address from the DHCP server.
The following Table 10 shows various types and usages of the DHCP messages shown in FIG. 9.
TABLE 10MessageUseDHCPDISCOVERClient broadcast to locate available servers.DHCPOFFERServer to client in response to DHCPDISCOVERwith offer of configuration parameters.DHCPREQUESTClient message to servers either (a) requestingoffered parameters from one server andimplicitly declining offers from all others,(b) confirming correctness of previouslyallocated address after, e.g., system reboot,or (c) extending the lease on a particularnetwork address.DHCPACKServer to client with configuration parameters,including committed network address.DHCPNAKServer to client indicating client's notion ofnetwork address is incorrect (e.g., client hasmoved to new subnet) or client's lease asexpiredDHCPDECLINEClient to server indicating network address isalready in use.DHCPRELEASEClient to server relinquishing network addressand canceling remaining lease.DHCPINFORMClient to server, asking only for localconfiguration parameters; client already hasexternally configured network address.
FIG. 9 is a diagram illustrating operations of a DHCPv4 system. Referring to FIG. 9, the DHCPv6 system is indicative of a DHCP protocol for the IPv4 system. Specifically, a method for controlling the DHCP client to automatically receive an IP address from the DHCP server will hereinafter be described with reference to FIG. 9 and Table 10. First, the client broadcasts a “DHCPDISCOVER” message at step S110. If individual servers receive the “DHCPDISCOVER” message from the client, they answer the received “DHCPDISCOVER” message and transmit a “DHCPOFFER” message as a response signal at step S120.
The client having broadcast the “DHCPDISCOVER” message receives the “DHCPOFFER” message from one or more servers, and selects one of the servers to request a configuration parameter. Thereafter, the client broadcasts a “DHCPREQUEST” message at step S130. In this case, servers not selected by the “DHCPREQUEST” message recognize that the client has declined their respective offers. The server selected by the “DHCPREQUEST” message includes address configuration information in a “DHCPACK” message, and transmits the “DHCPACK” message with the address configuration information as a response signal at step S140.
If the client receives the “DHCPACK” message from the selected server, it constructs an address at step S150. However, if the client receives a “DHCPNAK” message, the client re-starts the aforementioned process. The client may also transmit a “DHCPRELEASE” message to the server when returning a leased address at step S160.
FIG. 10 is a flow chart illustrating operations of a mobile IPv6 system. The mobile IPv6 system can more effectively support mobility of a mobile terminal than the mobile IPv4 system, and has superior extensibility. The principal components for the mobile IPv6 system operations and functions of individual principal components will hereinafter be described with reference to FIG. 10.
Referring to FIG. 10, a mobile node (MN) is a host or router switching its network access. A correspondent node (CN) is a host or router communicating with the mobile node (MN). A home agent (HA) acts as a router, and contains registration information of the mobile node (MN) obtained from other routers contained in a home network such that the HA can transmit a datagram to a current position of the mobile node (MN) contained in a foreign network. A temporary address or care of address (CoA) is indicative of an IP address connected to the mobile node when the mobile node moves to a foreign node.
A term “Binding” is indicative of a specific operation in which the mobile node matches the CoA registered in the home agent with a home address of a corresponding node. A “Binding Update (BU)” message is indicative of a message used when the mobile node itself informs the home agent (HA) and the correspondent node (CN) of a CoA of the mobile node. A “Binding Acknowledge (BACK)” message is indicative of a response message to the aforementioned “BU” message. A “Binding Request (BR)” message is indicative of a message for requesting the “BU” message when the correspondent node (CN) does not receive the “BU” message until a timer for the binding information of the mobile node expires.
A term “CoA acquisition” is indicative of a specific operation in which the mobile node automatically constructs its location information while in motion using a neighbor discovery function and an address auto-configuration function. A term “Router Optimization” is indicative of a specific procedure during which the correspondent node (CN) directly communicates with the mobile node without passing though the home agent after storing the binding information.
The above-mentioned address auto-configuration function is classified into two address auto-configuration methods. For example, a first method is a state-maintenance-type address auto-configuration method for acquiring an address using a server, such as the DHCP server. A second method is a non-state-type address auto-configuration method, wherein the mobile node controls a host to generate an address by itself.
The state-maintenance-type address auto-configuration method is adapted to assign one of a plurality of addresses capable of being assigned from the server to the host on the condition that the host requests an address from the DHCP server. The non-state-type address auto-configuration method combines the mobile node's interface ID information with prefix information acquired from the router, such that the mobile node forms an address.
Operations of the mobile IPv6 system shown in FIG. 10 will hereinafter be described. Referring to FIG. 10, if the mobile node (MN) moves from a subnet A to another subnet B at step S200, the mobile node (MN) recognizes that it has moved to another subnet B using prefix information of a Router Advertisement (RA) message and a Neighbor Unreachable Detection (NUD) mechanism at step S210.
The mobile node (MN) itself then acquires a temporary address or care of address (CoA) using the aforementioned address auto-configuration method at step S220. Thereafter, the mobile node (MN) transmits the “BU” message, such that the home agent recognizes the acquired CoA at step S230.
The home agent (HA) having received the “BU” message combines (or binds) the home address of the mobile node (MN) with a temporary address (CoA), and transmits a “BACK” message as a response signal to the “BU” message at S240.
The correspondent node (CN) firstly communicating with the mobile node (MN) does not recognize that the mobile node (MN) has moved to another subnet. Accordingly, the CN sets a destination address to a home address of the mobile node (MN), and transmits the resultant packet to the home agent (HA) at step S250. The home agent (HA) for managing the mobile node (MN) intercepts the packet of the correspondent node (CN), and performs tunneling of the packet to a current location of the mobile node (MN) at step S260.
If the mobile node (MN) receives the tunneled packet, it determines that the correspondent node (CN) having transmitted the packet does not have the binding information, and transmits the “BU” message to the correspondent node (CN), such that it informs the correspondent node (CN) of a CoA of the mobile node (MN) at step S270. The correspondent node (CN) having received the CoA of the mobile node (MN) stores the binding information, and directly communicates with the mobile node (MN) using the binding information at step S280.
FIG. 11 is a flow chart illustrating operations of a DHCPv6 system. Referring to FIG. 11, the DHCPv6 system is indicative of a DHCP protocol for the IPv6, and supports the state-maintenance-type address auto-configuration method. The DHCPv6 system is indicative of a specific mechanism by which an IP address, various information (e.g., routing information), and a network resource management function are concentrated on a small number of DHCP servers, resulting in reduction of maintenance costs.
The DHCPv6 employs two multicast addresses, such as an “All_DHCP_Relay_Agents_and_Servers” address and an “All_DHCP_Servers” address. The “All_DHCP_Relay_Agents_and_Servers” address is indicative of a link local multicast address, which is used by a client to allow the client to communicate with an agent contained in a link on the condition that a link local address of the agent is unknown. All servers and agents act as components of the above multicast group.
The “All_DHCP_Servers” address is indicative of a site local multicast address, which is used by a client or a relay when the client or the relay transmits a message to all servers or does not recognize unicast addresses of the servers, such that the client or the relay can communicate with a server. In order to allow the client to use the above-mentioned “All_DHCP_Servers” address, the client must have addresses of sufficient ranges at which the server arrives. All servers contained in a site act as components of the above-mentioned multicast group.
A variety of messages can be used for basic operations of the DHCPv6 system, such as a “SOLICIT” message, an “ADVERTISE” message, a “REQUEST” message, a “REPLY” message, a “RENEW” message, and a “RELEASE” message, for example.
The “SOLICIT” message is adapted for the client to recognize location information of the server, and is multitasked using the “All_DHCP_Servers” address. The “ADVERTISE” message is indicative of a response message to the “SOLICIT” message. If possible, the DHCP server answers the “SOLICIT” message.
The “REQUEST” message is adapted to acquire constituent parameters equipped with an IP address from the server selected by the client, and is multitasked using the “All_DHCP_Relay_Agents_and_Servers” address. The “REPLY” message is indicative of a response message to the aforementioned “REQUEST”, “RENEW”, and “RELEASE” messages.
The “RENEW” message is indicative of a message required when the client acquires an initially-allocated client address and the lifetime of the constituent parameters. The “RELEASE” message is indicative of a message required when the client returns at least one IP address to the server.
Operations of the DHCPv6 system shown in FIG. 11 will hereinafter be described. Referring to FIG. 11, the client transmits the “SOLICIT” message to the “All_DHCP_Servers” address to recognize location information of the server at step S310. Individual DHCPv6 servers then output the “ADVERTISE” message to answer the “SOLICIT” message at step S320. In this case, the “ADVERTISE” message includes prefix information.
Thereafter, the client selects one of the DHCPv6 servers, transmits the “REQUEST” message to the selected server, and at the same time requests an additional constituent parameter at step S330. The selected DHCPv6 server outputs the “REPLY” message to answer the “REQUEST” message at step S340.
The client having received the “REPLY” message transmits the “RENEW” message to the DHCPv6 server, such that it updates conventional constituent parameters and the lifetime of allocated addresses, and starts operation of a T1 timer at step S350. In this case, the reference symbol “T1” is indicative of a specific time during which the client accesses the server having acquired an old address to increase the lifetime of a current address.
The DHCPv6 server transmits then the “REPLY” message as a response signal to the “RENEW” message at step S360. Thereafter, the client outputs the “RELEASE” message when an allocated address is no longer used, such that a corresponding address is released at step S370.
FIG. 12 is a flow chart illustrating an IP address setup procedure. In more detail, the IP address setup procedure indicates operations conducted when the multi-mode mobile terminal is handed over to a new network, and a mobility management protocol of the new network is different from that of an old network.
Referring to FIG. 12, the old network supports the mobility management protocol of the mobile IPv4 system. The new network supports the mobility management protocol of the mobile IPv6 system. It is assumed that the multi-mode mobile terminal installs mobility management protocols of the mobile IPv4 system and the mobile IPv6 system into a stack.
If the multi-mode mobile terminal is handed over to a new network, it receives an “IP_Renewal_Indication” trigger signal, and performs a CoA re-establishment procedure. In more detail, the mobile terminal having used the mobile IPv4 as the mobility management protocol in an old network broadcasts the “Agent Solicitation” message to acquire a new CoA. However, the new network (to which the mobile terminal is currently handed over) provides the mobile IPv6 as the mobility management protocol, such that the “Agent Solicitation” message is discarded.
Accordingly, the mobile terminal does not receive an “Agent Advertisement” message in response to the “Agent Solicitation” message after a lifetime of the “Agent Solicitation” message expires. After reattempting to transmit the “Agent Solicitation” message several times, the mobile terminal determines that it cannot be further operated by the mobile IPv4, and performs a CoA setup procedure using the mobile IPv6 message.
As described above, provided that the multi-mode mobile terminal is handed over to a new interface network (i.e., a new network), and a mobility management protocol of an old network is different from that of the new network, the mobile terminal requires a very long period of time until it recognizes that it cannot be further operated by the mobility management protocol of the old network in the new network. Only then does the mobile terminal establish a CoA using a mobility management protocol of the new network. In other words, a lengthy time delay occurs prior to the mobile terminal determining that it cannot be operated by the old mobility management protocol of the old network in the new network and establishing a CoA using the new mobility management protocol.
Therefore, due to the above-mentioned problems, the mobile terminal for performing traffic transmission/reception in real time encounters a damaged packet and an extended service time.